GITEA en Entornos profesionales: Control y Soberanía del Código
Hay un momento en cualquier entorno de infraestructura crítica, de esos donde hablamos de switches core, routers o firewalls que separan la red corporativa de Internet, en el que alguien pregunta algo incómodo: “¿Dónde estamos guardando exactamente las configuraciones de red y quién tiene acceso real a eso?”
Y ahí empiezan los silencios.
Porque mientras las aplicaciones viven felices en repositorios SaaS, las configuraciones de dispositivos de red suelen estar dispersas, copias locales, backups automáticos, algún sistema de monitorización que guarda versiones…pero sin una estrategia clara de control, trazabilidad y soberanía.
En redes donde un cambio mal aplicado en un switch puede tumbar una planta industrial o dejar sin servicio a cientos de usuarios, el repositorio deja de ser un detalle operativo. Se convierte en un componente crítico.
Es en ese contexto donde Gitea empieza a tener mucho sentido.
Infraestructura crítica no es un laboratorio
Cuando hablamos de infraestructuras críticas no estamos hablando de un homelab ni de un entorno de pruebas. Estamos hablando de dispositivos que gestionan tráfico real, que soportan procesos de negocio y que, en muchos casos, están sujetos a auditorías formales.
Un cambio en un firewall mal documentado puede generar una brecha de seguridad. Una ACL modificada sin trazabilidad puede romper comunicaciones críticas. Un firmware actualizado sin registro puede complicar cualquier análisis forense posterior.
Herramientas como Oxidized permiten extraer y versionar automáticamente configuraciones de red. Plataformas como LibreNMS ayudan a monitorizar el estado de los dispositivos. Incluso soluciones comerciales como SolarWinds Network Configuration Manager ofrecen gestión avanzada de configuraciones.
Pero hay una pregunta que muchas veces no se aborda con suficiente profundidad:
- ¿Dónde vive ese versionado?
- ¿Quién controla el repositorio donde se almacenan esas configuraciones?
Ahí es donde entra Gitea como servidor Git autoalojado y bajo tu control total.
Gitea como repositorio soberano de configuración
Gitea no es simplemente “otro Git web bonito”. Es un servicio Git ligero, autoalojado y extremadamente manejable, diseñado para integrarse en entornos donde el control importa más que el marketing.
En un entorno crítico, usar un SaaS externo para almacenar configuraciones de routers o firewalls puede ser perfectamente válido, hasta que deja de serlo. Requisitos regulatorios, políticas internas o simplemente criterios de seguridad pueden exigir que el código, y en este caso, las configuraciones, no salgan de tu perímetro.
Con Gitea:
- El repositorio vive en tu CPD o en tu nube privada.
- El acceso se integra con tu directorio corporativo.
- El tráfico puede restringirse a redes internas o VPN.
- Los backups siguen tu política corporativa.
- La auditoría depende de tu stack, no del de un tercero.
Eso cambia radicalmente el nivel de control.
Integración real con Oxidized y gestión de cambios
El otro día os mostrábamos como uníamos Oxidized y LibreNMS en la misma infraestructura. Hoy queremos explicaros el valor al unir Gitea a la ecuación.
En escenarios prácticos, el patrón es bastante claro:
- Oxidized recoge automáticamente las configuraciones de switches, routers y firewalls.
- Cada cambio se convierte en un commit.
- Gitea actúa como repositorio central, gestionando historial, permisos y revisiones.
La diferencia respecto a usar un Git público es sutil pero clave, la superficie de exposición.
Cuando las configuraciones incluyen:
- Direccionamientos internos.
- Esquemas de VLAN.
- Reglas de firewall.
- Rutas estáticas o dinámicas.
- Información sensible de arquitectura.
Tener eso en un repositorio bajo tu propio dominio reduce dependencias y simplifica el cumplimiento normativo.
Y además, te permite algo que muchas veces se pasa por alto, aplicar el mismo modelo de revisión que en desarrollo de software.
- Puedes establecer pull requests para cambios de configuración críticos.
- Puedes exigir doble validación antes de aplicar una modificación estructural.
- Puedes mantener ramas diferenciadas para entornos productivos y de contingencia.
Eso es Git aplicado a infraestructura de red con disciplina real.
Integración Gitea como Stack Docker
Os explico brevemente como sería la integración con Oxidized. Generemos una carpeta persistente para el contenedor (usaremos portainer instalado en un NAS donde ya está Oxidized) y una subcarpeta en Oxidized:
Usaremos la red que ya comparten con LibreNMS, una buena práctica sería segmentar en más redes.
El stack para Gitea sería:
version: "3.8"
services:
gitea:
image: gitea/gitea:latest
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- GITEA__webhook__ALLOWED_HOST_LIST=oxidized
volumes:
- /home/cgsi_seg/docker/apps/gitea/data:/data
ports:
- "3000:3000"
- "2222:22"
networks:
- librenms_librenms_net
restart: always
networks:
librenms_librenms_net:
external: true
Tendríamos que actualizar el stack de Oxidized:
version: "3.8"
services:
oxidized:
image: oxidized/oxidized:latest
container_name: oxidized
restart: unless-stopped
ports:
- "8888:8888"
environment:
- TZ=Europe/Madrid
volumes:
- /volume2/Docker/oxidized/config:/home/oxidized/.config/oxidized
- /volume2/Docker/oxidized/repos:/home/oxidized/.config/oxidized/repos
- /volume2/Docker/oxidized/ssh:/home/oxidized/.ssh
networks:
- librenms_librenms_net
networks:
librenms_librenms_net:
external: true
Modificamos adicionalmente el fichero "config" de Oxidized para que use Gitea:
/volume2/Docker/oxidized/config/config
Modificamos la sección "output":
output:
default: git
git:
user: oxidized
email: oxidized@local
repo: git@gitea:oxidized/network-configs.git
Configuración Gitea para trabajar con Oxidized
- Accedemos a Gitea:
http://IP:3000
- Dejamos todo por defecto y pulsamos Instalar Gitea:
- Crear usuario:
oxidized
- Crear repositorio vacío:
network-configs
- Generar clave SSH en el contenedor Oxidized. La clave privada estará en el contenedor de Oxidized y la pública la subiremos a Gitea:
docker exec -it oxidized sh -lc 'ssh-keygen -t ed25519 -f /volume2/Docker/oxidized/.ssh/id_ed25519 -N ""'
O si lo hacéis en portainer como yo:
ssh-keygen -t ed25519 -f /home/oxidized/.ssh/id_ed25519 -N ""
- Aseguros que los permisos son:
chmod 700 /home/oxidized/.ssh
chmod 600 /home/oxidized/.ssh/id_ed25519
chmod 644 /home/oxidized/.ssh/id_ed25519.pub
ssh-keyscan -p 22 gitea >> /home/oxidized/.ssh/known_hosts
chmod 644 /home/oxidized/.ssh/known_hosts
- Copiar la clave pública a Gitea → Settings → SSH Keys
- Indicamos que Gitea usa la clave privada:
git config --global core.sshCommand "ssh -i /home/oxidized/.ssh/id_ed25519 -o StrictHostKeyChecking=accept-new"
- Probar conexión:
ssh -i /home/oxidized/.ssh/id_ed25519 git@gitea -p 22
- Clonamos un repositorio:
cd /home/oxidized/.config/oxidized
git clone git@gitea:oxidized/network-configs.git
Si responde correctamente, ya puedes hacer push.
Si quieres ver qué pasa en la autenticación
ssh -vvv -i /home/oxidized/.ssh/id_ed25519 git@gitea -p 22
Completas el stack en donde:
- LibreNMS: Monitoriza
- Oxidized: Extrae configs
- Gitea: Versiona y controla cambios
El valor estratégico de versionar red como código
Hay un cambio cultural importante cuando empiezas a tratar las configuraciones de red como código.
Dejas de depender del “administrador que sabe cómo está montado todo” y pasas a un modelo donde el conocimiento está documentado, versionado y trazable.
- Si alguien modifica un firewall a las 02:00, queda registrado.
- Si una ACL rompe un servicio, puedes comparar versiones y detectar qué cambió.
- Si necesitas reconstruir un equipo tras un fallo físico, el histórico está disponible.
Gitea, en este contexto, no es una herramienta accesoria. Es el repositorio oficial del estado de tu red.
Y eso tiene implicaciones serias en continuidad de negocio.
En caso de incidente, disponer de un histórico íntegro, bajo control interno y alineado con tus políticas de backup, puede marcar la diferencia entre horas de diagnóstico o días.
Adicionalmente, en infraestructuras críticas, el servidor de repositorios puede:
- Ubicarse en una zona de red segmentada.
- Requerir autenticación multifactor.
- Integrarse con SIEM corporativo.
- Ser monitorizado como cualquier activo crítico.
Control Real en entornos donde no hay margen
Conviene ser realistas. Gitea no sustituye una plataforma completa de gestión de configuraciones empresariales. No trae análisis avanzado de compliance ni validación automática de políticas de red.
Su fortaleza es otra, ser un servidor Git fiable, ligero y completamente bajo tu dominio.
Si tu organización ya dispone de herramientas de monitorización como LibreNMS y automatización complementaria, Gitea encaja como pieza central del versionado. Si buscas una suite que lo haga absolutamente todo, quizá necesites combinarlo con otras soluciones.
Pero esa modularidad es precisamente lo que muchos equipos valoran.
En infraestructura crítica no hay margen para la improvisación. Los switches core no entienden de experimentos. Los firewalls no perdonan errores mal documentados. Y las auditorías no aceptan explicaciones vagas.
Adoptar Gitea como repositorio soberano para configuraciones de red no es una moda DevOps aplicada a networking. Es una decisión de gobierno técnico.
- Significa asumir que el código, aunque sea código de red, es un activo estratégico.
- Significa que su historial debe estar bajo tu control.
- Significa que la trazabilidad no depende de terceros.
Puede parecer un detalle menor frente a routers de alto rendimiento o firewalls de última generación. Pero cuando algo falla y necesitas saber exactamente qué cambió, quién lo hizo y cuándo, el valor de tener ese histórico en tu propio servidor se vuelve incuestionable.
En entornos críticos, el control no es opcional. Y Gitea, bien implementado, es una forma pragmática y sólida de ejercerlo.
Fin del Artículo. ¡Cuéntanos algo en los Comentarios!
